1. Statement of the Technical Field
The present invention relates to the field of networking communications and, more particularly, to a method and system for leaking routes among routing engines via use of a routing distribution database.
2. Description of the Related Art
As will be apparent to one of ordinary skill in the art, communication networks include a number of network devices or nodes, which are connected via links or communication paths. One well known type of communication network is a packet network. A device for managing the flow of packets in a network is commonly known as a router. Routing is the act of moving information across a network from a source node to a destination node.
Routing and routing protocols involve two basic activities: determining optimal routing paths and transporting information groups, i.e., packets, through a network. Routing protocols use routing algorithms to determine the optimal path that the packet should travel to reach its destination. To aid the process of path determination, routing algorithms initialize and maintain routing tables which contain route information. Route information varies depending on the routing algorithm used. The router creates or maintains a table of the available routes and their conditions, and uses this information, along with distance and cost algorithms, to determine the best route for a given packet.
In highly scaleable networking devices, it is often desired to run multiple routing engines, where each engine services its own routing domain having its own addressing space. Each routing engine has its own set of routing protocol and policy configuration. Each engine's route selection is independent from one another. However, it is sometimes necessary to share or “leak” certain routes among routing engines. For example, one routing engine (e.g., Engine A) may service a Virtual Private Network (VPN) and another routing engine (e.g., Engine B) may service the public Internet. If a VPN user needs to access the Internet through Engine A, it is necessary to have the appropriate public interest (i.e., Internet) routes leaked from Engine B to Engine A.
A current method of leaking routes is to add an interface that connects the two routing engines and then run a dynamic routing protocol between the two engines over that connection. The interface could be a physical or a virtual interface. By applying appropriate routing filter, one or more selected routes can be exported and imported between routing engines. There are, however, drawbacks associated with leaking routes between routing engines by using a dynamic routing protocol.
Dynamic routing allows routing tables in routers to change as the possible routes change. A well known way of routing information between routers using Interior Gateway Protocol (IGP) for the specific case of dynamic routing is known as Routing Information Protocol (RIP). RIP obtains routing information for all possible routes in a network. RIP periodically broadcasts its routing table to neighboring routers. It sends requests to other routers for their routing tables and, as each router sends its routing tables, routes are calculated. However, networks utilizing RIP require a long time to stabilize after a router or a link fails, and require a great deal of bandwidth and overhead due to the constant broadcasting of messages and the repeated provision of route updates.
An example of the difficulty associated with the use of dynamic routing protocols to leak routes among routing engines is running a Border Gateway Protocol (BGP) on the interface. BGP uses Transmission Control Protocol (TCP) as a transport protocol. When two systems are using BGP, they establish a TCP connection and then send their BGP routing tables to each other. BGP detects failures by sending periodic “keep alive” or “hello” messages to its neighbors every 30 seconds. It exchanges information about reachable networks with other BGP systems, including the full path of systems that are between them. Thus, if there are N number of routing engines, and each engine needs to leak routes to each other engine, then there are N2 such interfaces that are needed. Therefore, the overhead increases drastically with the number of engines in the network. Obviously, this approach does not scale well when used for leaking routes among routing engines.
FIG. 1 represents a traditional way of leaking routes between two or more virtual routers. A classical approach that is often taken to leak routes between two or more virtual routers is to create a virtual link between the routers as shown in FIG. 1. In this example, virtual router-2 establishes a virtual link with virtual router-1, and establishes an IGP routing protocol, such as OSPF or RIP, over this link. The IGP for virtual router-2 uses its routing export protocols to export routes X that are to be leaked to router-1. Virtual router-1 uses its import routing protocols to add the exported routes X to a Routing Information Base (RIB).
Similarly, virtual router-2 can export routes X to router-3 over a virtual link between the two routers. Again, router-2 uses its export procedures to leak routes X over the virtual link to router-3. Virtual router-3 uses its route import procedures to add routes X to its RIB. Even though this approach capitalizes on the existing IGP infrastructure, the cost of leaking routes grows exponentially as the number of virtual routers sharing these routes increases. For example, if a virtual router shares routes with N other virtual routers, then it must create N virtual links and run IGP on each of those N links. Further, the exporting router needs to configure and execute routing export/import polices on each of these links for that IGP.
Creating virtual links also consumes memory resources and running IGP on those virtual links consumes memory as well as CPU resources. Executing routing polices also requires CPU resources. Thus, in the classical approach for leaking routes, the requirements on memory and CPU resources grows exponentially with the number of virtual routers. The approach illustrated in FIG. 1 requires each virtual link to be maintained, and because each virtual interface includes its own inherent overhead, adding virtual links to leak routes in this fashion is cumbersome, costly and expensive. The overhead increases drastically with the addition of each new virtual link.
Therefore, what is needed is an improved system and method for leaking routes between routing engines that resolves the scalability issue by requiring significantly less overhead and resources.